【書評】「プロジェクトマネジメントの基本が全部わかる本」の輪読会を開催していただいたので参加しました

コーヒーが好きな emi です。

7 月末～ 11 月末にかけて、私が所属しているチームのマネージャー 横田慎介 さん主導で「プロジェクトマネジメントの基本が全部わかる本」の輪読会を開催いただきました。おかげさまで一人では読み切れなかったであろう本が読み切れて嬉しいです。
本記事では開催いただいた輪読会の進め方と、私が「プロジェクトマネジメントの基本が全部わかる本」を読んだ感想を記載します。

既に書評ブログがありますので、詳細はこちらもご参照ください。

• 書籍タイトル : プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで
• 著者 : 橋本 将功
• 出版社 : 翔泳社
• 出版日 : 2022/11/08
• 出版社の書籍情報リンク：プロジェクトマネジメントの基本が全部わかる本 交渉・タスクマネジメント・計画立案から見積り・契約・要件定義・設計・テスト・保守改善まで（橋本 将功）｜翔泳社の本

輪読会とは

読み方：りんどくかい
人々が集まって、同じ教科書などの本を読み、その内容について意見を交わすことを意味する語。事前に決められた担当者が、本の内容を訳したりまとめたりしてから、他の参加者が理解できるように発表する形式がとられることも多い。
「輪読会(りんどくかい)」の意味や使い方 わかりやすく解説 Weblio辞書

ざっくりいうと、何か学びたい人たちが一緒に参考書や教科書などを読んで意見交換をする会です。

一人では読み切れないような本を題材に開催して、それぞれのメンバーが本の異なる部分を読み要点を共有すると、全員が本全体の内容を網羅的に把握することができます。
また、チームに足りない知識をみんなで学びたい時に開催すると、効果的に情報を共有し、理解を深めることができます。

輪読会の進め方

輪読会の進め方は以下のブログにとても詳しく書かれているので、ぜひ参考にしてください。

「プロジェクトマネジメントの基本が全部わかる本」の輪読会では、初回時にどのように進めたいか参加メンバー同士で決め、以下のように進行しました。

• 事前読書型
• 週一回、各回 1 章ずつ読む
• 各回のファシリテーション担当者を決めておき、担当者は当日までに章の要約をまとめて記載しておく
• 参会者は当日までに該当の章を読み、3 ポイントを書いてくる
  • 3 ポイント：自分が大事だと思った箇所や気になった個所、疑問に思った箇所、議論したい箇所などを 3 点選び、箇条書きする
• 当日はファシリテーション担当者が要点を見ながら該当の章に何が書かれていたか発表し、順番に各自の 3 ポイントを発表していく
• 自由に意見を言ったり議論したりする

以下のように Google ドキュメントでフォーマットを作っておき、それぞれ準備してきて輪読会当日に発表したり議論したりしました。

書籍の感想

特に印象に残った章に関して書いていきます。私はずっとインフラ基盤領域の設計・構築を担当してきたので、そういった立場で読んだ感想です。参加メンバーと議論して盛り上がった個所も記載しています。

以降、プロジェクトマネージャーのことを「PM」と略して記載します。

第1章 プロジェクトとはなにか―基本的な知識と考え方をおさえよう

「目的」と「目標」の違いについて明確に意識したことがなかったので印象的でした。
インフラ基盤領域で働いてきた私は「期限内の目標値の達成 = プロジェクトの成功」と考えてしまうことが多かったです。また、そもそもプロジェクトは計画段階のことがすべて実現できるとは限らず必ずと言っていいほど想定外のことが起こります。プロジェクトメンバーや各関係者がプロジェクトの目的を理解しておけば、有事に何を優先すべきかの方針を立てるのも、合意形成もやりやすくなることが分かりました。

プロジェクトの失敗パターンについての記載も興味深かったです。

第2章 交渉―適切なパートナーシップを築こう

私が今まで最も苦手としてきた分野で、この本の中で一番気になっていた章です。「交渉が苦手な PM は多い」と章の最初にも記載がありました。

交渉はなぜ必要なのか、交渉はなぜ難しいのかを説明した後に気を付けるポイントや具体的なコミュニケーションの方法が記述されており、実際の交渉の際に役立ちそうです。
私は「自分はエンジニアであり決裁者ではないから、こんな交渉をする権限はない！」と思ってしまうこともあったのですが、第1章で「プロジェクトの目的を達成するために尽力する」という視点を得た後でこの第2章を読むと身にしみるものがありました。
営業は接待などの関係、PM は一歩引いた関係を構築するなど、あらかじめフォーメーションを組むというのも印象的でした。プロジェクトはチームプレイですね。

また、以下の記述については輪読会でも議論が盛り上がりました。世代によっても意見が異なりそうです。

仕事仲間の相互理解を深めるために、飲み会を開催したり、チャットで雑談できるようにしたり、オフィスでパーティを実施したり、上司との 1on1 を増やしたりする企業は多くあります。しかし、こうした取り組みはプロジェクトのチームビルディングとして信頼関係を醸成することには直接貢献しません。

第3章 タスクマネジメント―チームでパスワークをしよう

学びは多かったのですが、私が想像していたタスクマネジメントと少し違いました。プロジェクトメンバーのアサインやメンバーチェンジなどについての記載が多かったです。

第5章 見積り―必要な費用とスケジュールを構想しよう

現場で回避できることとして「概算見積もりがひとり歩きして調整ができなくなる」「プロジェクトに余裕がなく不測の事態に対応できない」などの記載があり、経験したことがあるメンバーもいたと思います。

パラメトリック見積、３点見積、類推見積、ボトムアップ見積など具体的な見積方法が記載されていて、根拠のある見積作成に役立ちそうでした。

第6章 契約―不利な条件を回避しよう

準委任契約における「善管注意義務」については議論が盛り上がったと記憶しています。
IT プロジェクトにおける「通常期待されること」の基準はおそらく組織や人、プロジェクトによっても違うので、ある程度明文化する必要性を感じました。

善管注意義務とは｜違反事例、罰則、対策などわかりやすく解説 - カオナビ人事用語集

第7章 要件定義―やるべきことを決めよう

QCD（Quality（品質）、Cost（コスト）、Delivery（納期））の調整の観点については実際の案件でもかなり役に立っているのを経験しました。

コラムの「要件定義では「発散」と「収束」を意識しよう」についても印象的で、「○○したい」という要望はたくさん出て発散しやすいですが、それをプロジェクトに落とし込むために収束のフェーズであることを意識することで、スコープが無尽蔵に広がり過ぎる前に歯止めをかけることができそうです。

第9章 設計―専門家に渡すバトンをつくろう

「Done is better than perfect（やりきることは完璧であることよりも良い）」というマークザッカーバーグの言葉が引用されており、どのような形であれ設計書は必ず残すべきであることと、必ず設計が完璧でなければならないということではないということが書かれていました。

第11章 リリース―石橋を叩いて渡ろう

「年末年始やお盆など大型連休前のリリースは避け、どうしてもやるときはメンバーのプライベートを毀損していることを認識する」という内容にメンバーみんなが共感していました。このような考え方が世の中にもっと広まると良いですね。

第12章 保守改善―事業の成功につなげよう

想像していた保守改善の話とはちょっと違いました。メンテナンスのためのパッチ適用やサーバー再起動などシステム的な話想像していましたが、売り上げやマーケティングなどビジネス寄りの話でした。
私は基幹システムに携わっていた期間が長かったので、プロジェクトは「売り上げをあげるため」というより「必須だからどれだけ安くコスパ良く作れるか」というような観点でしか考えたことがありませんでした。
システムのお引き渡し以降、サービスのグロースまで考えるのが本当に良い PM なんだな…と思いつつ、PM が担う役割が多すぎて本当に大変だな、という感想を持ちました。

プロジェクトマネージャー、プロダクトマネージャー、スクラムマスターなど、プロジェクトには多様な役割があります。これは一人の PM だけで全てを担うのが困難なので、効率的なプロジェクト運営を実現するために生まれた役割なのかな、と想像しました。

終わりに

明確に PM について体系的に書かれている書籍を読んだことがなかったので、大変良い機会でした。PMBOK（Project Management Body of Knowledge）をしっかり腰を据えて学ぶとなるとかなり時間と覚悟が必要と思いますが、私のようなシステム基盤をメインで設計構築するアーキテクトにとってはちょうどよい分量だったと思います。

「この本にはこう書いてあるけど、自分はこういう風に逆境を乗り越えた」「こういうケースはこうやって対応してきた」など、ほかのメンバーの知見も学ぶことができてとても有意義でした。